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J. TO ALL WHOM IT MAY CONCERN: 

Jf BE IT KNOWN that we, Carolyn Faour, Paul Anderson, and Avi Bedi, 

O residing in the State of Texas, have invented new and useful improvements in a 

SYSTEM AND METHOD FOR HANDLING A UNIT OF WORK 

of which the following is a specification: 
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CROSS REFERENCE TO RELATED APPLICATION 

1 The present application claims the benefit of priority of US Provisional 

2 application No. 60/1 58,729, filed October 11,1 999, titled COMMON 

3 FRAMEWORK FOR SYSTEMS THAT MANAGE A UNIT OF WORK THROUGH 

4 ITS LIFE CYCLE. 

BACKGROUND OF THE INVENTION 

5 1 . Field of the Invention: 

5 6 The present invention relates generally to computer systems, and more 

ffl 7 specifically to a system and method for handling a work item within the system 

% 8 during that item's lifetime. 

f_ s 9 2. Description of the Prior Art: 

10 Numerous techniques are used to manage work that is to be performed. 

S 11 How that work is handled depends in part upon the nature of the work. In some 

12 applications, a single work item is worked upon by several different entities, 

13 human or automated systems, at different times. Work of this type is difficult for 

14 existing system to deal with, because keeping up with the work item and its 

15 status is not provided for. 

16 An example of such a system would be one associated with a "help desk", 

17 in which requests for assistance are submitted by users, and addressed at 

18 various times by technicians. When a user submits a request for assistance, that 
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1 request must be tracked as it passes through the system set up to deal with it. 

2 Such a request may be dealt with by a single technician, or it may be routed to 

3 one or more specialists for additional assistance. Such requests are sometimes 

4 referred to as "trouble tickets" in some industries. The trouble ticket must be 

5 maintained, and its status ascertained, until a response to the request is 

6 completed. 

7 Most computer systems have trouble gracefully handling this type of work 

8 item. In many cases, dedicated code must be written to enable these items to be 

9 tracked and handled. This is inefficient, because systems that deal with such 

10 work items have many features in common. 

11 It would be desirable to provide a system that enabled work items of this 

12 type to be easily handled. It would further be desirable for such a system to be 

13 generic enough that the numerous different business systems could use a single 

14 support system. 
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SUMMARY OF THE INVENTION 

1 In accordance with the present invention, a system and method for handling 

2 work items creates a work item object for each work item entered into the system. 

3 Each object maintains information regarding its state, and its type. Work items are 

4 maintained in queues, and each work item contains information identifying the 

5 queue it is in. Business processes, which may be controlled by people or 

6 automated modules, take items from queues, and perform actions on them. 

7 Actions modify the state of an item, and can alter its data. An item persists until the 

8 work it represents is completed. 



i-J 
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BRIEF DESCRIPTION OF THE DRAWINGS 

1 The novel features believed characteristic of the invention are set forth in the 

2 appended claims. The invention itself however, as well as a preferred mode of use, 

3 further objects and advantages thereof, will best be understood by reference to the 

4 following detailed description of an illustrative embodiment when read in 

5 conjunction with the accompanying drawings, wherein: 



6 Figure 1 is a block diagram illustrating a preferred common workflow 

7 domain; 

8 Figure 2 is a table identifying the contents of a preferred work item; 

9 Figure 3 is a diagram depicting a preferred composite action; 

10 Figure 4 is a flowchart outlining a process for handling work items; and 

11 Figure 5 is a block diagram illustrating data flows in a preferred embodiment 

12 of the present invention. 
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DESCRIPTION OF THE PREFERRED EMBODIMENT 

1 As will be appreciated by tnose skilled in the art, the detailed implementation 

2 of the preferred embodiment cam be made in numerous ways. Preferably, an 

3 object oriented environment is used\ as it easily represents the various objects and 

4 methods described below. However the described system and method can be 

5 used with systems of various types. 

The following discussion can be better understood with reference to an 
example. The invention is not limited a system implementing the described 

8 example, but it is used for explanatory purposes only. 

9 In a business that assists users with questions regarding products they have 

10 purchased, some technique is needed to track the status of numerous inquiries. 

1 1 One approach is to provide a "trouble ticket," a document that is passed around 

12 containing the history of resolving the help request, and other information relevant 

13 to the request. This can be conceptualized as a^physical document, a piece of 

14 paper, but is implemented as objects in a computer system domain. 

15 The trouble ticket, referred to herein generally as a "work item," is 

16 preferably an object in an object oriented computer system. A new work item is 

17 created when a help request is first made, and exists untlj the request is completely 

18 resolved. The work item can change state, be passeoyo various personnel at 

19 various locations for handling, and can be modified at various stages. IN addition, 
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1 actions can be performed at various stages along the way that are not related to 

2 modifying the work item itself. 

3 As an example, a user can contact a help line via a web page accessed over 

4 the internet. The user selects^category of problem being encountered, such as a 

5 hardware problem with a certain brand of laser printer. A description of the problem 

6 can be entered by a simple text description, or as a series or responses to 



questions posed. When the user has entered the required information, including 
identification of the user, a work item is generated that must be routed to technical 
fH p support and responded to. \ 



10 The work item can be placed into\a queue for technical support for that 

11 particular hardware. Eventually a techniciariuakes the work item from the queue, 

12 and determines whether the problem can be answered based on the information 

13 given. If not, additional handling may be required, or the technician may need to 

14 call or otherwise contact the customer for further information. The work item may 

15 need to be routed between several different people, even several different 

16 companies, before it is resolved. Once the problem\|ias been solved, which can 

17 include on-site repair or replacement, the work item is completed and archived. 

18 The preferred system handles the work item and its routing in a manner that 

19 is generic and can be used for numerous different business processes. 

20 Implemented as a software system running on a computer system, Figure 1 

21 illustrates a preferred domain for the system. Domain 10 allows access through 

22 interface 12, which is the published set of methods by which the domain can be 
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1 accessed. Contained within the\domain are a number of composite actions 16, 

2 described below, and work items 16. Numerous other support and other modules 

3 and objects are included in domairl 10 as known in the art, but the composite 

4 actions 14 and work items 16 are of primary conceptual interest. All access to the 

5 work items 1 6 is through the defined interface 1 2. 

6 Figure 2 describes the parts of a work item 16. Each work item 16 has a 

7 Category, which is used to determine, in part, how the work item 16 is handled. 

8 Each work item has a State, which indicates where the work item 16 is in the 

9 business process flow. Typical states could include new, pending, awaiting follow 
0 up, completed, and so forth. A State indicates whether the work item 16 is open or 

11 closed. An open item has been locked by a handler process, and work is being 

12 done on it. A closed item is waiting in a queue for work to be performed. 

13 Each work item 16 has a Location. All work items must be located in a 

14 queue, and the location identifies the queue the work item 16 is in. The Creator 

15 and Responsible fields indicate who created the work item 16, and who is 

16 responsible for dealing with it. The Responsible field can change during the course 

17 of handling the work item. The Due field, which may not be used in some cases, 

18 indicates when the problem represented by the work item\ must be resolved. This 

19 information can be used to, among other tings, prioritize worlc items in a queue. 

20 The History filed contains a history of all actions that nave been undertaken 

21 on this work item 16. Each time the item is amended in anyi way, or moved to a 

22 different queue, the history field is updated. By reviewing the History entry at any 
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1 time, the compete sequence of events relating to this work item 16 can be 

2 recreated. The Description field includes a definition of the problem represented by 

3 the work item, and can include text and coded indicators. 

4 Figure 3 shows a composite, action 14. Each composite action 14 contains a 

5 rule, which is a Boolean expression that gives an answer of True or False. The rule 

6 can be omitted. By linking a series\of composite actions together in sequence, 
nearly any business process can be defined by using composite actions 14. 

8 Three sets of actions are provided. A first set 18 is executed by default 

9 when the composite action has no rule, or\when the rule is not evaluated because 

10 of a setting. A second set of actions 20 is\executed when the Rule evaluates to 

11 True, and a third set of actions 22 is evaluated when the rule evaluates to False. 

12 These actions are any which can be executed by the system. Typical actions 

13 include sending the work item to a particular queue, sending e-mail or fax 

14 messages to the customer or a technician, and similar types of notifications. The 

15 actions can be more complex, and initiate various actions to be performed by the 

16 system. For example, an action could include access to a database of expert 

17 knowledge about a certain problem, followed by display of suggested solutions to a 

18 technician. 

19 In the preferred embodiment, each Rule has tWee possible outcomes. If 

20 desired, other outcomes can be accommodated, with multi-way logical branching 

21 occurring. Each outcome of the rule evaluation can hav^ a separate set of actions 

22 to be executed, in the manner described above. 
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1 Figure 4 is a flowchart illiistrating the preferred system in action. Initially, a 

2 work item is created 30; a trouble ticket in the help desk example described herein. 

3 When a work item 16 is created, It is assigned a category. Categories are 

4 preferably arranged hierarchically, so that a user can better define the problem by 



5 selecting a lower category. In the previous example of a printer hardware problem, 

6 high level categories can include, for example, hardware and software problems, 

7 with lower levels defining with more precision the type of hardware having the 

8 problem and the nature of the problem itself. 

Each category has an associated composite action 14. When a work item is 
10 ' initially created, the composite action for the associated category is executed on the 



11 work item. Actions may include, for example, an^-mail notification that the work 

12 item has been entered, and an estimate of the delay before it will be handled. The 

13 work item must be initially placed into a queue, so ^ach possible set of actions for 

14 the composite action associated with a category must have an action that places 

15 the work item into a queue 32. 

16 At some future time, the work item is extracted from the queue. This can be 

17 done by an application executing automatically, or by a person calling up the work 

18 item through an application operating on her computerA When a work item is 

19 opened, it must be locked so that another application! cannot access it. A 

20 composite action is executed on the work item 34, as described above. 

21 The composite action can be executed by a technician after reviewing the 

22 work item. For example, after a technician opens a workyitem relating to a 
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1 hardware problem with a prifiter, the technician will take an initial step toward 

2 resolving the problem. In some cases, it may only be necessary to send a 

3 prepared reply to the customeAexplaining how to deal with a known, common 

4 problem. In others, I may be necessary to initiate a more complicated series of 

5 actions to resolve the problem. Ffor example, it may be that the symptoms, 

6 although appearing to be hardware related, are actually caused by software. The 

7 technician may then need to transfer the work item to a different queue for 

8 processing, and send a notification to the customer that this has happened. 

The technician accomplishes activities such as this by selecting an 

llO appropriate action from a menu or other presentation on her computer display. The 

11 selected action then calls the corresponding composite action, which in turn 

12 executes the actions according to the result of its rule. As mentioned previously, 

13 these actions can include modifying the work item, moving it to a different queue, 

14 sending notifications, and so forth. Whenever a composite action is executed, the 

15 work item history is updated to reflect all changes. 

16 If the result of the composite action is to change the work item status to 

17 complete 36, the work item is closed 38 and archived. If processing of the work 

1 8 item is not yet complete it is placed in a queue for Mure processing. 

19 The result of a composite action may be to leave the work item in the same 

20 queue for future handling, or to move it to a different queue. In either case, 

21 processing of e work item is similar. Also, an action in a composite action may be 

22 to execute another composite action. This would result in a sequence of two or 
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1 more composite actions being executed on the work item with no additional input 

2 from a technician or the\customer. By defining the composite actions, a complex 

3 workflow can be performed on the work item in step 34. Generally, eventually the 

4 work item is placed in a queue to await an action or decision to be performed by a 

5 person, but this is not a requirement. 

Figure 5 illustrates a conceptual data flow that can occur in the system 
described above. A work item is\initially created by an appropriate process 40 as 

8 described above. Transport of wo\k items within the common workflow domain is 

9 represented by line 42. The work item is placed into one of queues 44, 46, 48. 

10 Eventually, it will be picked up by theVassociated handler 50, 52, 54, respectively, 

11 and operated upon. Operations by a handler 50 - 54 include the execution of one 

12 or more composite actions. At the end of such execution, the work item is placed 

13 into another queue for further processing. \ As described above, in many cases the 

14 processing to be performed by a handler executes as the result of a selection made 

15 by a person after deciding how to deal with the work item. 

16 Queue 56 is used for holding work itemsuhat are completed, and process 58 

17 finishes the task of completing and archiving completed work items. When the 

18 work item has been completely responded ta as defined by the business 

19 processes defined by the composite actions, the wo\j< item 1 6 is placed in queue 56 

20 for final disposal. 

21 The described system and method allow for certain types of businesses 

22 processes to be efficiently handled in comparison with prior art systems. A trouble 
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1 ticket ion connection witn a help desk has been described as an example, but 

2 numerous other situations are suitable for the system and method of the invention. 

3 For example, nearly any customer relationship that requires several different people 

4 to wok on could use the described processes. Whenever any piece of work must 

5 be handled by different entities at different times, the described system and method 
can usually be defined to handle the process. 

While the invention has been particularly shown and described with 

8 reference to a preferred embodiment, it will be understood by those skilled in the art 

9 that various changes in form and detail may be made therein without departing from 

10 the spirit and scope of the invention. 



Patent Application.doc/40015 



Page 13 



